User-specified key creation from attributes independent of encapsulation type

ABSTRACT

An integrated circuit has a hardware decoder that parses a frame to identify a type of encapsulation. The integrated circuit also has a number of hardware parsers, each parser being coupled to the decoder by an enable line. During packet processing, one of the parsers is enabled by the decoder, based on the value which identifies the encapsulation type. The enabled parser retrieves one or more attributes from the frame, depending on the encapsulation. The integrated circuit also has a register, coupled to each parser. The register holds the attributes retrieved by the parser. The integrated circuit also has a key generation hardware which creates a key, by concatenating from the attributes register, certain attributes that are pre-selected by a user for forming the key. The integrated circuit supplies the key to a memory to look up a set of user-specified actions to be performed on data in the frame.

CROSS-REFERENCE TO PARENT AND GRANDPARENT APPLICATIONS

This application is a continuation application of U.S. application Ser.No. 12/371,528 filed on Feb. 13, 2009 by Cedell A. Alexander, Jr.entitled “USER-SPECIFIED KEY CREATION FROM ATTRIBUTES INDEPENDENT OFENCAPSULATION TYPE” which in turn is a continuation application of U.S.application Ser. No. 10/893,117 filed on Jul. 16, 2004 by Cedell A.Alexander, Jr. entitled “USER-SPECIFIED KEY CREATION FROM ATTRIBUTESINDEPENDENT OF ENCAPSULATION TYPE” now U.S. Pat. No. 7,492,763. U.S.application Ser. Nos. 12/371,528 and 10/893,117 are both incorporated byreference herein in their entirety, including all Appendices.

CROSS-REFERENCE TO COMPUTER PROGRAM LISTING APPENDIX

Appendix A contains the following file, submitted herewithelectronically, in IBM-PC format and compatible with Microsoft Windows.Appendix A is a part of the present disclosure and is incorporated byreference herein in its entirety.

07/16/2004 03:05p      29,223 parser.txt      1 File(s)    29,223 bytes     0 Dir(s)      0 bytes free

The file “parser.txt” in Appendix A forms source code of a computerprogram (in the form of C language) for documenting the implementationof certain circuitry used in an illustrative embodiment of the presentinvention, containing an encapsulation-dependent hardware block, asillustrated in FIG. 3 and described below. The code in Appendix A is inthe C language and provides a behavioral description of the hardwareused in one specific illustrative embodiment.

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the patent and trademarkoffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND

1. Field of the Invention

The invention relates to processing of packets. More specifically, theinvention relates to a method and an apparatus for determining from aframe, one or more attributes (e.g. VLAN tag) that are at differentlocations in the frame depending on the type of encapsulation, and useof one or more such attributes to create a key as specified by a userand use of the key to identify instructions to be executed alsospecified by the user.

2. Related Art

U.S. Pat. No. 6,587,463 that is incorporated by reference herein in itsentirety describes packet classification by use of a rule memory and acriterion memory. Control logic responds to packet classificationrequests by retrieving from rule memory an operator and a pointer to anentry in criterion memory. The operator defines a comparison operationto be performed between comparands from criterion memory andcorresponding values from a received packet. The results are provided toa packet processor to take an appropriate action.

U.S. Pat. No. 6,598,034 that is also incorporated by reference herein inits entirety describes a set of rules that are developed and stored foruse by a Just-In-Time (JIT) compiler, a run-time compiler or the like.The rules establish a set of patterns, and the incoming data is comparedto those patterns. If certain patterns are detected, then the associatedaction established by the rule is applied to the processing of the datapacket.

U.S. Pat. No. 6,718,326 which is incorporated by reference herein in itsentirety describes use of a CAM which has a limited bit width to searchrules of packet classification having very long search bit width. Thefields of rules of packet classification are grouped into groups, andthe grouped fields of each rule are stored along with search relatedinformation (except for the initial group) and number of searchinformation in a CAM.

Certain prior art network processors may be programmed, in software, toprocess packets that are encapsulated in frames whose headers haveformats of the type shown in FIGS. 1A-1G, which are as follows:

FIG. 1A—Ethernet v2 untagged

FIG. 1B—802.3 untagged

FIG. 1C—SNAP untagged

FIG. 1D—Ethernet v2 with 1 VLAN tag

FIG. 1E—Ethernet v2 with 2 VLAN tags

FIG. 1F—SNAP with 1 VLAN tag

FIG. 1G—SNAP with 2 VLAN tags

To handle packets that are encapsulated in frames of multiple formats,it is common for a prior art network processor to be programmed, by theuser, to contain a rule for each of the above-listed sevenencapsulations (FIGS. 1A-1G). Specifically, the user is required to haveknowledge of the format of the above-listed seven encapsulations and torepeatedly perform the programming, once for each encapsulation.

SUMMARY

An integrated circuit has at least one input port to be coupled to anetwork, to receive a frame from the network. The integrated circuitalso has a hardware decoder that is coupled to the input port toretrieve at least one value that is located at a predetermined locationin the frame. The value at the predetermined location identifies a typeof encapsulation, such as Ethernet v2 or 802.3 with or without one ormore VLAN tags. The integrated circuit also has a number of hardwareparsers, each parser being coupled to the decoder by an enable line,each parser being further coupled to the input port.

During processing of a received frame, one of the parsers is enabled bythe decoder, based on the above-described value which identifies theencapsulation type. The enabled parser retrieves one or more attributesof the frame, based on a format for the encapsulation that is hardwiredinto the parser. The integrated circuit also has a register, coupled toeach parser. The register holds attributes of the frame that have beenretrieved by the parser from different locations in the frame, dependingon the encapsulation.

The integrated circuit also has a key generator which creates a key byconcatenating values of certain attributes from the received frame thatare pre-selected by a user for forming the key. The integrated circuitsupplies the key to a memory (which may be either in the integratedcircuit i.e. on-chip or outside the integrated circuit i.e. off-chip) tolook up a set of user-specified actions to be performed on data in theframe. The actions may be specified by the user in the form ofinstructions to a processor also included in the integrated circuit. Theinstructions may include an instruction to enable one or more additionalsearch operations to be performed on attribute values of the receivedframe.

BRIEF DESCRIPTION OF THE FIGURES

FIGS. 1A-1G illustrate prior art formats of headers in frames ofdifferent encapsulations.

FIG. 2A illustrates, in a high-level block diagram in accordance withthe invention, an encapsulation dependent hardware block and anencapsulation independent hardware block, with user specifications forgeneration of a key being supplied to the encapsulation independenthardware block.

FIG. 2B illustrates, in a high-level flow chart in accordance with theinvention, acts performed in some embodiments of circuitry shown in FIG.2A.

FIG. 3 illustrates, in an intermediate level block diagram, anencapsulation dependent hardware block that includes a decoder and anumber of hardware parsers that are coupled to the decoder to receive anenable signal therefrom.

FIG. 4 illustrates, in an intermediate level block diagram, anencapsulation independent hardware block that includes multiplexers anda compressor to generate a key, and memories that are coupled to thecompressor to receive the key to be used to look up the memory.

FIG. 5 illustrates an exemplary implementation of the intermediate levelblock diagram of FIG. 3.

FIG. 6 (including FIGS. 6A and 6B) illustrates an exemplaryimplementation of the intermediate level block diagram of FIG. 4.

FIG. 7 illustrates a state machine that is used for an encapsulationdecoder as per some embodiments of the invention.

FIG. 8 illustrates an integrated circuit that uses the circuitry of FIG.2 with other hardware blocks such as a Policing Unit (SPU), statisticscounters, packet classification CAM, queue manager, admission controllogic, scheduling engine, transformation engine, memory manager and datafirst-in-first-out (FIFO) memory, to process packets in some embodimentsof the invention.

FIGS. 9, 10, 11, 12, 13, 14, 15A, 15B, 16 and 17 illustrate, in tables,various parameters, attributes, fields and their related descriptions asdiscussed in Attachment C.

DETAILED DESCRIPTION

A circuit 200 (FIG. 2A) in accordance with the invention has twohardware blocks 210 and 220 that are respectively dependent on andindependent of a type of encapsulation used to embed data in frames thatare received at one or more input ports 201 of circuit 200. Circuit 200of many embodiments is implemented as a single integrated circuit asdiscussed below, although in other embodiments it can be implemented ina combination of two or more integrated circuits.Encapsulation-dependent hardware block 210 of some embodiments extractsattributes that are located at different positions in a frame, dependingon the frame's encapsulation type. Encapsulation-independent hardwareblock 220 of these embodiments selectively uses certain of theattributes, in a manner specified by the user, to generate a key.

Integrated circuit 200 supplies the key to a memory 230 (which may beeither in the integrated circuit i.e. on-chip or outside the integratedcircuit i.e. off-chip), to look up a set of user-specified actions to beperformed on data in the frame. Note that in several embodiments, thekey is used directly or with additional information concatenatedthereto, to perform a memory look up, without any logic processing onthe key. For example, no logical “AND”, “NOT” and “OR” operations areperformed on the key in such embodiments. Moreover, actions that areidentified by the memory look up, for performance on the frame, may bespecified by the user in the form of instructions to a processor 240(which may also be either on-chip or off-chip). A processed framegenerated by processor 240 after execution of the instructions may betransmitted on one or more of output ports 202, into a network to whichports 201 and 202 are coupled.

Note that in the above-described embodiments, the user specifies how akey is to be generated based on attributes that have already beenextracted by encapsulation-dependent hardware block 210. For thisreason, in many embodiments in accordance with the invention, eachattribute to be used to form the key is specified by the usersymbolically, without reference to a corresponding location in the frameat which the attribute is located for each type of encapsulation. Forexample, a VLAN tag field is symbolically specified by the user (e.g. asbeing “attribute 3”), for inclusion in a key, without specifying each offour different locations at which this field occurs in certainencapsulations that are supported in some embodiments of the invention.Locations that are not specified by the user, when using a VLAN tagfield symbolically, are shown in Table A as octets that are at differentlocations for each encapsulation

TABLE A FIG. ENCAPSULATION TYPE Octets FIG. 1D Ethernet v2 with 1 VLANtag 14, 15 FIG. 1E Ethernet v2 with 2 VLAN tags 18, 19 FIG. 1F SNAP with1 VLAN tag 22, 23 FIG. 1G SNAP with 2 VLAN tags 26, 27

Hence, the user need not specify physical locations of a field (e.g. asshown in the above table) to be used in key generation. Instead, suchlocations are hard-coded into encapsulation-dependent hardware block 210in accordance with the invention. As noted above, block 210automatically extracts the VLAN tag field (in this example) and makes itavailable for use (along with several other such attributes) independentof physical locations of attributes in the frame.

Several advantages accrue to an architecture of the type shown in FIG.2A wherein attributes are made available independent of physicallocations in the frame. First, the user need not know the physicallocations of various attributes in different types of encapsulations.Second, the user needs to specify just a single attribute value, for allencapsulation types. Therefore, in some embodiments of the invention,the number of rules used in the prior art is reduced (proportional tothe number of encapsulations that are supported), thereby to improveefficiency (save storage). Furthermore, a user interface is simplifiedin such embodiments because the attributes are specified symbolicallyand only one value is specified for multiple encapsulation types.

Some embodiments of the invention perform a method 290 (FIG. 2B) asfollows. Specifically, in act 291, integrated circuit 200 receives fromthe user a symbolic indication of one or more attributes of a frame touse in key creation. Note that in act 291, integrated circuit 200 doesnot receive an indication of a location in the frame for eachencapsulation (i.e. a fourth register in an attribute register file,also called “attribute 3” may be used to hold the value of a VLAN tag).Integrated circuit 200 also receives, in act 292, a set of instructionsto be executed when attributes of a frame have values that match certainvalues that are also specified to integrated circuit 200 by the user.Note that such values (to be checked against a frame's values) arespecified in act 292. Integrated circuit 200 stores the values receivedin acts 291 and 292, either in on-chip memory or in off-chip memory(depending on the embodiment). After performance of acts 291 and 292,integrated circuit 200 is now ready for use in processing frames (andpackets embedded within the frames), as discussed next.

Specifically, when a frame is received (as per act 298 in FIG. 2B),integrated circuit 200 identifies (as per act 293), from a value at afixed location in the frame, a type of encapsulation of data in theframe. For example, if the value of octets 12 and 13 (which form a“type” field or a “length” field depending on encapsulations) is greaterthan or equal to 1536 then the encapsulation type is identified as beingEthernet v2 and otherwise the encapsulation type is identified as beingIEEE 802.3. Hence, checking of the value of octets 12 and 13 in eachframe is performed, in some embodiments, by a hardware decoder 211 thatis included in some embodiments of encapsulation-dependent hardwareblock 210 (FIG. 3). Such a block 210 implements the following functionin hardware, wherein Packet_Type=1 if the packet is Ethernet v2, andPacket_Type=0 if 802.3:

if ([octet 12, octet 13] < 16′d1536 ) then Packet_Type = 0 elsePacket_Type = 1;

Referring to FIG. 2B, the result of act 293 is used in act 294 to enablea parser implemented in hardware to be used for the identifiedencapsulation type, and the rest of the frame is decoded by the enabledparser. Specifically, in act 294, an appropriate one of hardware parsers212 shown in FIG. 3 is enabled depending on the type of encapsulation(e.g. parser 212A is enabled if the type of encapsulation is “A” andalternatively parser 212B is enabled if the encapsulation type is “B”),and on being enabled it extracts one or more attributes of the frame,from predetermined location(s) appropriate for that type ofencapsulation. Attributes that are extracted from the frame header arealso referred to as “layer-2” attributes.

For example, if the encapsulation is Ethernet v2 with one VLAN tag, thenassume that hardware parser 212A (also called “Layer-2 parser”) isenabled and so parser 212A retrieves a layer-2 attribute called “VLANtag” from octets 14 and 15 of the frame. As another example, if theencapsulation is SNAP with one VLAN tag, then assume that hardwareparser 212B is enabled and so parser 212B retrieves a VLAN tag fromoctets 22 and 23 of the frame.

Note that although only two Layer-2 parsers 212A and 212B are shown inFIG. 3 for illustrative purposes, any number of Layer-2 parsers may beincluded in encapsulation-dependent hardware 210 in accordance with theinvention. Note that in some embodiments there are as many Layer-2parsers as the number of encapsulations that are supported. Theextracted attributes are supplied, by whichever hardware parser 212 wasenabled, to a register 213.

Depending on the embodiment, certain hardware parsers 212 of FIG. 3 mayextract attributes from a payload of the frame, such as Layer-2.5attributes (in which case they are also called “Layer-2.5 parsers”) orLayer-3 attributes (in which case they are also called “Layer-3parsers”). Such attributes are typically embedded within headers thatare located in the frame's payload portion and the related parsers neednot be implemented in all embodiments.

Next, as per act 295 in FIG. 2B, the values in register 213 are used togenerate a key, by use of attributes that are symbolically pre-selectedby the user. Note that the attributes in register 213 are independent ofencapsulation. It is the names of these attributes (such as the name“VLAN tag” which may be represented internally as “attribute 3”) thatare made available to the user, via a Graphical User Interface (GUI) 401(FIG. 4) for symbolic selection by setting up values for parameters in aregister file 402. During frame processing by the above-describedintegrated circuit, these parameters (labeled “PARAMETER A” . . .“PARAMETER N” in FIG. 4) are automatically used to select one or morevalues from register file 213 (i.e. values of user-specifiedattributes), and optionally one or more values from header octets 405.The selected values from file 213 and octets 405 in turn areconcatenated and compressed (as noted in the next paragraph) whengenerating a key.

Specifically, a set of multiplexers labeled “MUX 1” . . . “MUX N” inFIG. 4 use the user input in register file 402 to select one or morevalues of attributes in register 213 and/or header octets. The valuesselected by the multiplexers (labeled in FIG. 4 as “key field 1” . . .“key field N”) are supplied to a compressor 221. Compressor 221 removeszero or more padding bits from the values supplied by the multiplexersand concatenates them to form a key (e.g. in “key field 1” only the loworder bits that are “field size 1” in number have valid values and theremaining bits are stripped off before concatenation with other suchfields).

Next, as per act 296 (FIG. 2B), a newly-created key (shown in FIG. 4 asbeing held in a register 409) is used to read memory 230, to identifyinstructions that are to be executed. These instructions are supplied toand executed by processor 240 as per act 297 in FIG. 2B. Above-describedacts 293-297 are performed in several embodiments whenever a frame isreceived, as shown by the dashed line 299. Note that hardware 220 (FIG.4) consists of only multiplexers and a compressor, and for this reason,this hardware 220 is independent of the type of encapsulation.

An exemplary implementation of encapsulation-dependent hardware 210 isillustrated in detail in FIG. 5. As shown in FIG. 5, a stage 1 containstwo blocks of memory, specifically a table 501 of port records and alatch 502 that holds octets from the header of a frame. The port recordstable 501 receives as input the identifier of a port on which a frame(to be processed) has arrived. In response to the port identifier (alsocalled Ethernet port number), the port records table 501 provides arecord containing values (which may be either user-specified orhardwired) descriptive of the port, such as the default VLAN tag, taggedVLAN EtherType-1, tagged VLAN EtherType-2.

In some embodiments, such values are configurable by the user, asdescribed below. Such port-descriptive information is used in threeLayer-2 header parsers, namely an Ethernet header parser 212A, a SNAPheader parser 212B and an 802.3 header parser 212C, wherein “SNAP” is anabbreviation of “Subnetwork Access Protocol” which is detailed in IETFRFC 1042. The RFC 1042 is incorporated by reference herein in itsentirety.

Some embodiments that support VLAN tags may use, in octets 12 and 13(see FIG. 1D) of a frame, a value for the type field other than thevalue x8100 defined in IEEE 802.3 standard to indicate the presence ofVLAN tags, e.g. the value x9100 may be used in the first type field(octets 12 and 13 in FIG. 1E) to indicate the presence of multiplenested VLAN tags and the value x8100 may be used in the second typefield (octets 18 and 19 in FIG. 1E). For this reason, several suchembodiments of an integrated circuit 200 allow the user to set, for eachspecific port, two values (specified as tagged VLAN EtherType-1 andtagged VLAN EtherType-2) to be used by the integrated circuit 200 inparsing frames that are received on that specific port.

Stage 1 of FIG. 5 supplies certain specific octets from the header, e.g.octets 12-16 in one implementation, to stage 2 which contains a hardwaredecoder 211 of the type described above. The hardware decoder 211 instage 2 generates a value called “ethEncap” which is used as an enablesignal to one of the three hardware parsers 212A-212C in stage 3(described above). Only one of the three Layer-2 header parsers isenabled to process any given frame. When enabled, the a Layer-2 headerparser uses the port-descriptive information (described above), andcertain octets from the frame's Layer-2 header (which are different foreach parser) to store in register file 213 the following attributes:packetType, etherType, ssap, dsap, VLAN tag count, VLAN tag, nested VLANtag, and L2 payload offset, which attributes are described next.

The attribute packetType represents a signal internal to an integratedcircuit of the type described above, and this attribute has threedifferent values: IP, MPLS and Layer-2 (where Layer-2 means anythingother than IP and MPLS). The attribute etherType is same as the typefield in octets 12 and 13 of the frame formats as illustrated in FIGS.1A, 1D, 1E and 1G, and has values of the type described above. Theattributes “ssap” and “dsap” are source and destination “service accessports” that are fields in a logical link control (LLC) header shown inFIG. 1B. The attributes “ssap” and “dsap” represent the source anddestination ports for the LLC connection. For more information on LLCparameters, see IEEE 802.2 standard that is incorporated by referenceherein in its entirety.

Moreover, the attribute VLAN tag count is either 0, 1 or 2 whichindicates the number of VLAN tags that were found in the frame, and itis a signal internal to an integrated circuit of the type describedabove. Furthermore, VLAN tag is the outermost VLAN tag if the framecontains a VLAN tag, and if the frame is untagged then a user-specifieddefault VLAN tag associated with the port is used as the VLAN tag. Notethat in such embodiments, the attributes register holds a VLAN tag forevery frame regardless of whether or not the frame contains the VLANtag. The attribute nested VLAN tag is the innermost VLAN tag in theframe (if the VLAN tag count is 2). Moreover, the attribute L2 payloadoffset is the location where the Layer-2 payload begins, after eachheader shown in FIGS. 1A-1G.

The embodiment illustrated in FIG. 5 also contains two additional headerparsers in a stage 4. Specifically, stage 4 header parsers receive asinput two attributes generated by stage 2, namely: L2 payload offset andpacketType. Note that an output line of the stage 3 that carries theattribute packetType is coupled to an enable line of the parser in stage4. In addition, each header parser in stage 4 receives certain octetsfrom the frame header as follows: an IP header parser 212Y receivesoctets 14, 18, 22, 26 and 30 whereas an MPLS header parser 212Z in stage4 receives octets 16, 20, 24, 28 and 32.

Each of these stage 4 header parsers 212Y and 212Z then stores inregister file 213 (FIG. 3) one or more attributes that are extractedfrom a layer-2 payload (e.g. IP header parser 212Y generates theattributes “IP payload offset” and “dscp,” whereas the MPLS headerparser generates the attribute “exp”). Note that the attribute “dscp”stands for “differentiated services code point” which is defined in RFC2474 that is incorporated by reference herein. Moreover, the attribute“exp” stands for a three bit field in the MPLS label called“experimental bits”, as defined in RFC 3031.

In an exemplary illustration shown in FIG. 6, register file 213 ishardwired in integrated circuit 200, to hold the following attributes.Note that the organization of file 213 can be different in otherembodiments. A first element of register file 213 is Attribute 1 whichis hardwired to be the Ethernet port number (on which the frame isreceived). The second element of attributes register file 213 isAttribute 2 which is hardwired to be the Ether Type (which is atdifferent locations in the frame, depending on the encapsulation). Thethird element of attributes register file 213 is Attribute 3 which ishardwired to be the VLAN tag (which is also at different locations inthe frame, depending on the encapsulation). The fourth element ofattributes register file 213 is Attribute 4 which is hardwired to causethe selection of an offset in the IP payload (which is at differentlocations in the frame, depending on the encapsulation). Finally, thefifth element of attributes register file 213 is Attribute 5 which ishardwired to be the L2 payload offset (which is also at differentlocations in the frame depending on the encapsulation).

As noted above, the hardware for key generation in integrated circuit200 contains storage elements that are user configurable in the form ofa number of register files 402A-402N (wherein N, e.g. 64, is the numberof register files; see FIG. 6). Having a set of register files 402A-402Nenables the user to configure a corresponding number of keys (otherwisethe user would be forced to apply only a single key to all frames). GUI401 provides a mechanism for the user to load any desired values intoeach of register files 402A-402N (also called “parameters” registerfiles 402A-402N). Specifically, the user may load values in registerfile 402A from a device external to the integrated circuit, such as apersonal computer that executes graphical user interface 401.

Note that although there are N register files, only one register file402I is enabled during packet processing for use as discussed above inreference to FIG. 4, e.g. by a select signal on bus 675. Specifically,in some embodiments, a register file may be initially enabled via bus675 in response to a user-configurable value in a port record of a porton which a frame is received (see output of table 501 in FIG. 5). Insuch embodiments, another register file may be enabled at a later timefor use with attributes of the same frame, e.g. via a select signal onbus 241 that is supplied by processor 240. Processor 240 may supply sucha select signal while executing instructions that were identified by useof an initial key that is generated from the initially enabled registerfile (as identified in the port record). Note that processor 240, whenidentifying a register file, may do so as a part of the identity of asearch operation that also contains, for example, the databaseidentifier and the database type.

A group of storage elements 602 in register file 402A for each parameter(labeled “PARAMETER 1” . . . “PARAMETER 6” in FIG. 6) contain at leasttwo portions in the embodiment illustrated in FIG. 6, namely anattribute ID register 602A and an offset register 602O. The value inregister 602A is loaded by the user to symbolically identify thelocation of an attribute to be used in the key, from the attributesregister file 213. Note that although in FIG. 6, only six parameters areshown as being available to prepare a key, any fixed number (e.g. 16)parameters may be available in a given architecture, depending on theembodiment.

The attribute identifier specified in any given PARAMETER I is used by acorresponding MUX I to select a specified attribute value from registerfile 213 and supply the selected value on an output bus to compressor221. Each PARAMETER I also contains a storage element to hold anidentifier of an offset into the frame header, from which an appropriateoctet is supplied by the corresponding MUX I on the output bus tocompressor 221. Note that in this embodiment MUX I also obtains fromattributes register file 213 the size of the attribute value that isbeing retrieved from register file 213 (and if present the size of theoffset value), and passes the size to compressor 221.

In the exemplary illustration in FIG. 6, the user has configured theparameters register file 402 as follows. The registers for PARAMETER 1are configured by the user to cause MUX 1 to select the Ethernet portnumber by specifying the attribute ID to be value 1 in register 602A.Note that there is no offset for PARAMETER 1 and for this reason MUX 1sets the size to be 4 bits in its output to compressor 221. The user hasalso configured the registers for PARAMETER 2 to cause MUX 2 to selectthe VLAN tag, by specifying the attribute ID to be value 3. Once again,there is no offset for PARAMETER 2 and for this reason MUX 2 sets thesize to be 16 bits in its output to compressor 221 (which is the size ofthe VLAN tag). The user has further configured the registers forPARAMETER 3 to cause MUX 3 to select the Ether Type, by specifying theattribute ID to be value 2. Once again, there is no offset for PARAMETER3 and for this reason MUX 3 sets the size to be 16 bits in its output tocompressor 221 (which is the size of the Ether Type). Note that all ofthe configuration described in this paragraph has been done by the userby simply identifying the relative locations of the attributes inattribute register file 213 (e.g. the values 1, 3 and 2 were identifiedrespectively for PARAMETERs 1, 2 and 3), without any referencewhatsoever to any physical locations of the corresponding values in aframe. Therefore, the user specifies the key without regard to theencapsulation of each frame.

The registers for PARAMETER 4 are symbolically configured by the user tocause MUX 4 to select a byte in the L2 payload, by specifying theattribute ID to be value 5. Note that here the user must specify anoffset of the desired byte, relative to the beginning of the L2 payloadfor PARAMETER 4 which has been specified to be of value 9. Hence, duringframe processing, MUX 4 selects a single byte located at offset 9 fromthe beginning of the L2 payload and also MUX 4 sets the size to be 8bits in its output to compressor 221. As seen from FIGS. 1A-1G, thebeginning of the L2 payload (which begins after the L2 header) changesdepending on the encapsulation. For example, L2 payload begins at octet14 in FIG. 1A, at octet 17 in FIG. 1B, at octet 22 in FIG. 10, at octet18 in FIG. 1D, at octet 22 in FIG. 1E, at octet 26 in FIG. 1F and octet30 in FIG. 1G. Regardless of what the encapsulation of a given frame is,MUX 4 automatically selects the byte at offset 9 from the L2 payload.

Similarly, the user has symbolically configured the registers forPARAMETERs 5 and 6 to cause the respective MUXes 5 and 6 to select therespective bytes in the IP payload, by specifying the attribute ID to bevalue 4. The only difference in the user's configuration of PARAMETERs 5and 6 is the relative location of the byte to be returned, which is 2and 3. Note that in making the configurations described in thisparagraph (and in the previous paragraph), the user made no referencewhatsoever to any physical locations in a frame (and did so without anyconcern about the type of encapsulation). Instead, in these examples,the user merely specified locations of the bytes to be retrievedrelative to beginning of the L2 payload or relative to the beginning ofthe IP payload which could be different in each frame, depending on itsencapsulation.

As shown in FIG. 6, the values generated by MUXes 1-6 are used bycompressor 221 with their relative sizes, to strip off the padding bitsand concatenate the remainder to form key 409 (which in this examplehappens to be 60 bits long). Key 409 is then used with memory 230 toidentify instructions to be executed by processor 240. In this exemplaryembodiment, memory 230 includes a ternary CAM 610 that is configured bythe user via GUI 401 to include a number of entries, each entryconsisting of a search value and a mask, including the following entry(wherein each character in the following hexadecimal representation isfor a nibble, i.e. 4 bits):

column 1 column 2 column 3 column 4 column 5 value 0x2 0x0080 0x08000x06 0x0050 mask 0xF 0x0FFF 0xFFFF 0xFF 0xFFFFIn the above entry in the ternary CAM 610, the user must specify valuesin the same order and size as the order and size of the valuesconfigured in the corresponding parameters register file 402, in orderfor frames containing the matching values to be identified. In theexample illustrated above, the user is specifying that the matchingframe must have arrived on port 2 (as per column 1 in above table) ofintegrated circuit 200, because the most significant nibble in the keywas used by the user (when configuring the registers for PARAMETER 1) torepresent the Ethernet port number (which is 4 bits long in thisexample).

In a similar manner, the user is specifying that the matching frame musthave a VLAN ID of 0x0080 (as per column 2 in above table). Note that insome embodiments, the VLAN ID occupies only the least significant 12bits of the VLAN tag (which is 16 bits long). As the user doesn't careabout the upper nibble of the VLAN tag, hence the mask value is set to“0FFF” in the second row of column 2 in the above table (with the “0”specifying don't care and the “F” specifying a match). Therefore, onlyframes with VLAN ID of 128 will match the above-described TCAM entry.Also, as per column 3 in the above table, the user is specifying thatthe matching frame must have an Ether type (which is 16 bits long) of0X0800 which means that the matching frame contains an IPv4 packet (inmost embodiments).

In the above illustrative TCAM entry, the user has specified (by thevalue 0x06 in column 4) that the just-described frames containing IP v4packets must have the 8-bit value 0x06 at byte offset 9 from thebeginning of the L2 payload. This value 0x06 indicates the presence of apacket in the TCP format of the Internet Protocol (IP). Finally, theuser has specified by requiring two bytes (total of 16 bits) at therespective IP payload offsets 2 and 3 to have the value 0x0050 (whichtranslates to value 80 in decimal), so that the matching frame containsan embedded TCP/IP packet addressed to the destination port 80, commonlyused for the HTTP protocol.

In the embodiment illustrated in FIG. 6, a result of the search isprovided by TCAM 610 as an index into a static random access memory(SRAM) 620 that contains a set of instructions to be executed byprocessor 620. Note that the user loads any desired instructions intoSRAM 620 via the GUI 401, in the normal manner. In some embodiments, theSRAM 620 merely provides a jump instruction for processor 240 to load aset of instructions in RAM 630 that serves as the “main memory” forprocessor 240. The instructions to be executed by processor 240 from RAM630 may be any instructions of the type well known in the art andcommonly used for packet processing. Furthermore, in some embodiments, aregister 409 that holds the key generated by compressor 221 is useddirectly as an index into RAM 630 instead of being used in TCAM 610.

In some embodiments, TCAM 610 may be designed to have one or moreadditional fields in each entry, such as a database identifier 611(shown dashed in FIG. 6 and not shown in the above table). Such adatabase identifier may be used with or without the Ethernet portnumber, to enable a user to uniquely specify a search pattern for agiven architecture of integrated circuit 200 (e.g. depending on thetotal number of ports). In several embodiments, a database identifier isprovided when a search operation is identified, along with the type ofdatabase (e.g. CAM or RAM), and the register file to be used (from amonga number of register files) for generation of a key.

Moreover, in some embodiments, a single register file 402 which holdsthe user-specified parameters for preparation of the key may beaddressable by processor 240 with instructions prepared by the user toload new values into register file 402, resulting in preparation of anadditional key for a given frame. The additional key which is again heldin register 409 (thereby overwriting the initially generated key forthis frame), is used in the above described manner, to once again find aset of instructions to be executed by processor 240 (either from theSRAM 620 or from the RAM 630 depending on the embodiment).

In some embodiments, decoder 211 (FIG. 3) is implemented incombinational logic after the entire header of an incoming frame hasbeen accumulated, although other embodiments use sequential logic, suchas a state machine, to implement decoder 211 as illustrated in FIG. 7.Specifically, the state machine of FIG. 7 starts in state 701 and goesto state 702 to skip the first 12 octets (labeled octets 0-11 in FIG.1A) of an incoming frame. Next, in state 703, the thirteenth byte(labeled byte 12) is examined for being equal to value 0x81. In thismanner, the state machine parses the incoming data of a frame, on abyte-by-byte basis as shown in FIG. 7. Each state transition representsa new byte being examined by the state machine. This state machine iseasily implemented in hardware using common sequential logic designmethods.

Note that this state machine (shown in FIG. 7) is limited to decodingthe number of VLAN tags, the value of the first VLAN tag, and the valueof the next (nested) VLAN tag. Also note that the Packet_Type field(either MPLS or IP) is not decoded by this state machine (shown in FIG.7) as it is not needed for this case. Instead, an independent statemachine that operates in parallel decodes this field, and other fieldslike it. Also, in this embodiment, the VLAN tag values are cleared atthe beginning and therefore need not be explicitly cleared when it isdetermined they are invalid.

Note that the state machine illustrated in FIG. 7 is merely an exampleto show how the VLAN tags are decoded instead of using combinationallogic. Hence, although a staged architecture is illustrated anddescribed in reference to FIG. 5, as will be apparent to the skilledartisan, such hardware may be implemented by use of one or more statemachines of the type illustrated in FIG. 7.

Moreover, the above-described combination of attribute extractionhardware 210, attributes register file 213, key generation hardware 220,parameters register file 402, and processor 240 (together referred tobelow as a configurable search engine) may be used as illustrated inFIG. 8 with a number of other blocks that are commonly used in anintegrated circuit for performing packet processing, in the normalmanner. For example, the frame that is received on a port (such as aGigabit Ethernet port formed by a GE MAC block and a physical connectionsublayer shown at the bottom of FIG. 8) is held in a dataFirst-In-First-Out memory that supplies the frame's data to block 210 inthe configurable search engine. Also, a key generated by block 220 inthe configurable search engine is used with a packet classification CAMto identify a set of instructions (also called “profile”) to be used inany one or more of processor 240, policing unit, statistics counters,admission control block, queue manager, scheduling engine andtransformation engine.

Several of the just-mentioned blocks are described in a generic mannerin Attachment B and in a more detailed manner in Attachment C, for anillustrative embodiment of the invention. Each of Attachments B and Clocated below just before the claims is an integral portion of thispatent application and is incorporated by reference herein in itsentirety. Moreover, a detailed description of how to parse a receivedframe to retrieve its attributes is provided in the C language in a filenamed “parser.txt” in APPENDIX A attached hereto in electronic form. Asnoted above, “parser.txt” is incorporated by reference herein in itsentirety.

The description herein is presented to enable one to make and use theinvention, and is provided in the context of particular applications andtheir requirements. It is not intended to be exhaustive or to limit theinvention to the forms disclosed. Various modifications to the disclosedembodiments will be readily apparent, and the general principles definedherein may be applied to other embodiments and applications withoutdeparting from the spirit and scope of the invention. Thus, theinvention is not intended to be limited to the embodiments shown, but isto be accorded the widest scope consistent with the principles andfeatures disclosed herein. Accordingly, many modifications andvariations will be apparent to the skilled artisan in view of thedisclosure.

For example, although a packet processor of some embodiments isdescribed as being built to use a content addressable memory oralternatively as a random access memory, other architectures may be usedfor efficient storage of such information. For this reason, manyembodiments of the packet processor support both kinds of memories RAMand CAM.

Numerous such modifications and adaptations of the embodiments andvariants described herein are encompassed by the appended claims.

ATTACHMENT B

Network processors of the prior art often face competition fromfixed-function ASICs for packet processing applications. A strongadvantage provided by network processors is the flexibility afforded byprogrammability. This flexibility minimizes the cost of correctingerrors and lengthens the hardware life cycle by enabling adaptation toevolving requirements via software-based enhancements. Conversely,network processors typically do not achieve the price/performance ratioof fixed-function ASICs. Additionally, there is a perception thatnetwork processors can be difficult to program. Thus, the flexibilityafforded by network processors comes at a cost.

A user-configurable packet processor in some embodiments of theinvention uses a hybrid approach that can be viewed as a new class ofpacket processors, which provide the following advantages:

-   -   1) maintain a significant percentage of the flexibility afforded        by network processors,    -   2) achieve a price/performance point that is much closer to that        of fixed-function ASICs, and    -   3) provide the flexibility in a simpler manner.

Hence the user-configurable packet processor of many embodiments is notprogrammed with a procedural language to classify incoming frames;instead, the search operation of the packet processor is controlled bythe user symbolically identifying a set of attributes of a frame, andcorresponding values that a matching frame is to have. The userconfigures this information into the packet processor in the form ofparameters which provide flexibility, but do so at a higher level ofabstraction that is simpler to use by a user. While the user-specifiedparameters do provide significant flexibility, they are constrained to apre-defined set of network-specific operations that are implemented inhardware, which enables better price/performance.

-   -   Note that an example instantiation includes:    -   a set of 12 Gigabit Ethernet (GE) line interfaces,    -   a system interface (with options for full-rate SPI-4.2, ¼ rate        SPI-4.2, or 2 GEs),    -   two Extended Feature Interfaces (EFIs) that support off-chip        expansion of memory/lookup resources,    -   a configurable search engine, and    -   a set of hardware co-processors that include:        -   a Packet Classification Content Addressable Memory (CAM),        -   a Policing Unit (SPU) that implements rate-limiting            algorithms,        -   Statistics Counters,        -   a Queue Manager,        -   an Admission Control block,        -   a Scheduling Engine, and        -   a Transformation Engine.

For illustration purposes, consider the following packet processingflow:

-   -   1) a packet is received on a GE line interface,    -   2) an initial search operation is selected based on the packet        format and configuration information,    -   3) the search key is formed by extracting the required        information,    -   4) the key is used to perform a search operation,    -   5) the result of the search operation indicates a set of actions        to be performed, which may invoke hardware co-processors;        additionally, one of the possible actions can select a set of        parameters to be used for a subsequent hierarchical search        operation, which implies repeating steps 3-5,    -   6) after all search operations have completed, a queue is        selected for the packet,    -   7) admission control is performed to determine if the packet is        admitted to the queue,    -   8) subsequently, the scheduling engine selects the packet for        transmission,    -   9) the Transformation Engine then executes a set of commands        that result in the packet being transmitted on a system        interface, while possibly also transforming the packet contents.

A configurable search engine of the type described above is a coreelement of several embodiments. Most of the other blocks are derivativesof technology that is currently used in AMCC network processor products.The Configurable search engine not only contains new technology, butalso integrates existing blocks in a new manner that enables theabove-described advantages to be realized.

In many embodiments, the functions implemented by the configurablesearch engine include:

-   -   parsing of received packets and selection of initial search        operation,    -   extraction of information required to form search key,    -   initiation of search operation,    -   interpretation of search results, and    -   management of action execution.

To further clarify operation of several embodiments, separatesubsections are devoted to each of the following topics:

-   -   packet attributes,    -   configuration of search parameters,    -   selection of initial search operation,    -   extraction of search key,    -   search operations,    -   search results,    -   action execution,    -   queue selection,    -   admission control,    -   scheduling, and    -   packet transformation.

As noted elsewhere herein, a set of attributes is associated with eachreceived packet. Each packet attribute has a value that is initializedby hardware. Some attribute values may also be explicitly set by actionsspecified in search results. Attribute values provide information thatmay be used during subsequent processing steps, such as queue selection,admission control, and packet transformation. In some cases, attributevalues control subsequent processing steps, while, in other cases,attribute values are used as data. The following table contains anexample set of packet attributes.

Example Set of Packet Attributes Attribute Value Port Number Identifiesinterface that packet was received on. Encapsulation Identifies packetencapsulation type. Examples for Type Ethernet frames include Ethernetv2, IEEE 802.3 SNAP, or IEEE 802.3 non-SNAP. VLAN Tag Count Number ofVLAN Tags associated with packet. VLAN Tag VLAN Tag associated withpacket. VLAN STP State Spanning Tree Protocol state. DSCP/EXPDifferentiated Services CodePoint for IP packet, or value ofEXPerimental bits for MPLS packet. Color Green, Yellow, or Red.Transformation Identifies a particular profile that contains a set ofProfile ID commands to be executed by the Transformation Engine. UserData Defined by user, set by search result actions.

The configurable search engine provides a flexible mechanism for theuser to configure a set of search operations. The following tablecontains an example set of parameters that might be used to configure asearch operation.

Example Set of Search Operation Parameters Parameter DescriptionDatabase Type Specifies type of database to be searched. For example,whether the database is implemented in a CAM or in RAM, and whether thedatabase is implemented with internal or external memory resources.Database ID Identifies a particular database to be searched. Count ofKey Number of key definition parameters in Definition Parametersfollowing list. List of Key Definition List of parameters that specifythe key Parameters to be used for the search operation.

Based on the above table, a search operation is configured by the userspecifying the database to be searched and the key format to be used forthe search. The key format to be used is configured by specifying a listof key definition parameters. The following table contains an exampleset of key definition parameters.

Example Set of Key Definition Parameters Parameter Description PortNumber Identifies interface that packet was received on. EncapsulationType Identifies packet encapsulation type. Examples for Ethernet framesinclude Ethernet v2, IEEE 802.3 SNAP, or IEEE 802.3 non-SNAP. EtherTypeThis parameter is specific to Ethernet frames. or It contains theEtherType value from the packet DSAP/SSAP header when the encapsulationtype is Ethernet v2 or IEEE 802.3 SNAP; otherwise, it contains the{DSAP, SSAP} values from the packet header when the encapsulation typeis IEEE 802.3 non-SNAP. VLAN Tag Count Number of VLAN Tags associatedwith packet. VLAN Tag VLAN Tag associated with packet. Nested VLAN TagSecond VLAN Tag associated with packet (only applicable when multipleVLAN Tags are associated with packet). VLAN STP State Spanning TreeProtocol state. Packet Offset Field at configured offset from start ofpacket. L2 Payload Offset Field at configured offset from start oflayer-2 payload. IP Payload Offset Field at configured offset from startof IP payload. User Data Attribute Field at configured offset withinUser Data Offset Attribute associated with packet.

The key definition parameters shown in the above table provide value ina number of ways. First, the parameters enable keys to be defined usinghigher levels of abstraction. To illustrate this point, consider theEtherType value, which identifies the layer-3 protocol. The exactlocation of the EtherType field in the packet header varies dependingupon the encapsulation type and the number of VLAN tags that arepresent. However, use of EtherType key definition parameter enables theuser to specify that the EtherType value be included in the search key,without having to worry about where the EtherType value actually residesin the packet header. This abstraction is not only a considerablesimplification, but also saves significant lookup resources that wouldotherwise be required to decode the various packet header combinations.The same value proposition arguments can be made for the other keydefinition parameters that represent packet-header abstractions.

To further clarify the preceding point, consider that the layer-3protocol type could be determined with a Ternary CAM (TCAM) databaseusing only the Packet Offset key definition parameter, which enableskeys to be formed with fields that are at specific offsets from thestart of the packet. However, the determination would require multipleTCAM entries, and when combined with other, similar search criteria, themultiplicative effect can create an explosion of TCAM size requirements.

As we have seen, the key definition examples include a set of moregeneric offset-based parameters. In addition to the previously discussedPacket Offset parameter, the set includes L2 Payload Offset, IP PayloadOffset, and User Data Attribute Offset parameters. The L2 Payload Offsetand IP Payload Offset options are higher-level abstractions of thePacket Offset parameter. The value of the abstractions is based on thefact that the layer-2 and IP payloads are not always located at fixedlocations within the packet. For a TCP/IP packet, the L2 Payload Offsetparameter simplifies access to fields in the IP header, while the IPPayload Offset parameter simplifies access to fields in the TCP header.

The User Data Attribute Offset parameter enables fields from the UserData Attribute associated with the packet to be included in search keys.Since values can be assigned to User Data Attribute fields as the resultof search operations, the User Data Attribute Offset parameter enablesthe results of a previous search operation to provide input to asubsequent hierarchical search.

A particular instantiation of a configurable search engine may supportdefinition of many search operations (e.g., 64 or more). Therefore, aquestion arises as to which definition should be used for the initialsearch operation performed on a received packet. One solution, would beto identify the definition to be used for the initial search operationvia configuration by the user. However, the desired search key can varybased on the protocol type, for example. Therefore, a better solution,in terms of flexibility and efficiency, is to enable configuration ofmultiple definitions, where each definition is associated with, forexample, a different protocol type. As an example, consider a solutionthat supports configuration of 4 different initial search operations,with one configuration for each of the following protocols:

-   -   IPv4,    -   IPv6,    -   MPLS, or    -   non-IP/MPLS protocols.

To implement this approach, the configurable search engine containshardware capable of performing the packet header parsing necessary toidentify the protocol type.

Hardware packet parsing capabilities of the Configurable search engineare also utilized to form the search key based on the key definitionparameters. In the running example we have been using, the hardwarecapabilities include parsing of:

-   -   Ethernet v2, IEEE 802.3 SNAP, or IEEE 802.3 non-SNAP MAC header        formats,    -   VLAN Tag and Nested VLAN Tag header formats, and    -   IPv4, IPv6, and MPLS protocol headers.

After forming the key, the Configurable search engine hardware initiatesthe search operation on the appropriate database. As mentioned earlier,the database may be implemented in a TCAM or in RAM, and the databaseimplementation may be internal or external to the packet processor. ARAM-based search operation might be as simple as using the key as anindex into a table.

The basic result of a search operation is a database entry that isassociated with the search key. The database entry can specify a set ofactions that are to be performed as a result of matching the searchoperation request. The following table contains an example set of searchresult actions.

Example Set of Search Result Actions Action Description Set CounterUpdate counter (e.g., add 1 or length of packet in octets). DiscardPacket Discard this packet. Set VLAN Tag Attribute Set value of VLAN TagAttribute associated with packet. Set DSCP Attribute Set value of DSCPAttribute associated with packet. Set User Data Attribute Set value ofUser Data Attribute associated with packet. Police Subject packet torate-limiting algorithm. Set Queue Select queue that packet is to bebuffered in. Set Interface Select interface that packet is to betransmitted on. Set Transformation Select profile that is to be executedfor packet Profile ID Attribute by Transformation Engine. Set SearchOperation Select next search operation to be performed, or indicate thatthis was the final search to be performed for packet.

An integrated circuit containing the configurable search engine may alsocontain hardware that interprets and executes the actions specified bythe search result database entry. In some cases, execution of an actionmay be implemented by invoking a hardware co-processor. For example, thepolicing unit is invoked as part of implementing a Police Action in theabove table. The specific manner in which the Police Action isimplemented provides another example of value via flexibility.

The policing unit of some embodiments supports multiple rate-limitingalgorithms, including the Single Rate Three Color Marker (srTCM),defined in RFC 2697, and the Two Rate Three Color Marker (trTCM),defined in RFC2698. Both the srTCM and the trTCM provide a color-awaremode of operation, where the color of the packet is an input to thealgorithm.

The configurable search engine supports color-aware operation in asimple, but flexible manner based on Pre-Color Mapping Tables. An IPPre-Color Mapping Table is used for IP packets and a MPLS Pre-ColorMapping Table is used for MPLS packets. The DSCP Attribute of an IPpacket is used as an index into the IP Pre-Color Mapping Table.Similarly, the EXP Attribute of a MPLS packet is used as an index intothe MPLS Pre-Color Mapping Table. Each Pre-Color Mapping Table Entryindicates whether the color input to the rate-limiting algorithm shouldbe GREEN, YELLOW, RED, or the value of the Color Attribute associatedwith the packet. In this manner, the user is able to control the inputsto the rate-limiting algorithm.

The result of the rate-limiting algorithm is also a color. Rather thanimpose fixed semantics on the color, the Configurable search engine usesa set of Policing Result Mapping Tables to determine the action that isto be taken. Nine Policing Result Mapping Tables are used, where a setof 3 tables are used for IP packets, a set of 3 tables are used for MPLSpackets, and a set of 3 tables are used for non-IP/MPLS packets. In eachset of 3 tables, one table is used when the rate-limiting result isGREEN, a second table is used when the result is YELLOW, and a thirdtable is used when the result is RED. Similar to the Pre-Color MappingTables, the DSCP Attribute is used as an index into the IP PolicingResult Mapping Tables, and the EXP Attribute is used as an index intothe MPLS Policing Result Mapping Tables. Each Policing Result MappingTable Entry may indicate a set of actions to be performed, such asdiscard the packet, initiate flow control, set the DSCP/EXP Attribute,and/or set the Color Attribute.

After all search operations have completed, a queue is selected for eachreceived packet. As discussed previously, the queue can be explicitlyselected by a search result action. However, if the queue is notexplicitly specified, a flexible mechanism, based on the followingtables, is employed for queue selection:

-   -   DSCP=>Queue Mapping Table,    -   EXP=>Queue Mapping Table, and    -   VLAN Priority=>Queue Mapping Table.

Naturally, the DSCP=>Queue Mapping can be used for IP packets, and isindexed using the DSCP Attribute. Analogously, the EXP=>Queue MappingTable can be used for MPLS packets, and is indexed using the EXPAttribute. The VLAN Priority=>Queue Mapping Table can be used for anypacket, and is indexed used the VLAN Priority component of the VLAN TagAttribute. Each Queue Mapping Table Entry identifies a specific queue.

Once the queue is selected, admission control is performed to determineif the packet will be admitted or discarded. Admission control is usedto manage the available buffer memory in times of congestion due tooversubscription. The basic idea is to allocate the memory in accordancewith the Quality of Service (QoS) policies in effect. The exact form ofthe admission control algorithm is not fundamental to this invention. Aset of admission control algorithm options could be provided, such asWRED, or the Dynamic Threshold Group Algorithm that is used in multipleAMCC network processor/traffic management products. The Color Attributeof the packet is used as an input to some admission control algorithms,including WRED and Dynamic Threshold Groups.

Subsequent to being admitted to a queue, packets are scheduled fortransmission. The scheduling can be performed with conventionalalgorithms, such as Strict Priority and Weighted Round Robin, and mayinclude features such as Max Rate Capping. As was the case withadmission control, the exact form of the scheduling algorithm is notfundamental to this invention.

After a packet is selected by the scheduling algorithm, theTransformation Engine executes a set of commands that can result in thepacket being transmitted on an interface. The commands may alsotransform the packet contents prior to transmission. For example, thefollowing types of transformations could be performed:

-   -   addition of new data to the packet (e.g., a new header/trailer),    -   deletion of a portion of the packet data, and/or    -   modification of the value of a particular field in the packet        (such as the DSCP field of an IP packet header).

The group of commands that is executed by the Transformation Engine isreferred to as a profile, and a particular instantiation of theinvention may support definition of many profiles that perform differentpacket transformations. The particular profile that is executed for agiven packet is determined by the value of the Transformation Profile IDAttribute. The values of other Packet Attributes are available asparameters to the commands executed by the Transformation Engine. Forexample, the values of the Packet Attributes can be included in thepacket data. Additionally, the values of the User Data Attribute can beused as pointers to constant data stored in memory local to theTransformation Engine.

Note that the packet transformation operations could be performedearlier in the packet processing flow, such as prior to the queuingstep, without any fundamental impact to the operation of a configurablesearch engine of some embodiments.

ATTACHMENT C

An integrated circuit called “nPC2315” in the form of an Ethernet MACcontroller is described herein as an illustrative embodiment of theinvention that provides high levels of functionality at disruptive costpoints by integration of key system features. More specifically, thenPC2315 is targeted at Gigabit Ethernet (GE) applications in both LANand WAN, with support for both flexible media-speed operation andintelligent oversubscription. The nPC2315 devices used in Enterpriseboxes—aggregation layer, distribution layer—as well as Enterpriseappliances such as VPN gateways, Content switches, Load balancers, andso on. The nPC2315 devices are also used in WAN Access, Edge and CoreRouters, and Switches as the high-functionality Ethernet aggregationfront-end into these boxes.

The nPC2315 is a 12-port Intelligent Oversubscribed MAC with one SPI-4.2uplink (wire rate and oversubscribed modes) or 2xGMII uplinks withembedded memory and flexible options for external memory (both payloadand context) and coprocessor interfaces (TCAM or external coprocessinglogic). Intelligent oversubscription in a MAC device enables a costeffective migration to 10/100/1000 ports without needing to upgradeexisting chassis in the field. Not all L2/L3 functions are required toenable intelligent oversubscription and offer Class of Service (CoS).Therefore, there is an opportunity for an intelligent MAC device that isoptimized to perform these functions and complement existing siliconimplementations. The nPC2315 employs the AMCC industry-leading trafficmanagement technology to manage oversubscription and provide Quality ofService (QoS) across the ports. The nPC2315 also performs advancedpacket classification, policing, statistics collection, and packetmarking functions. The nPC2315 is defined as an evolutionary solutionand is designed to be complementary to the existing L2/L3 forwardingsubsystems, allowing end customers to upgrade to higher densitylinecards, conserve precious processing resources in the system, and notcause any forklift upgrade to existing systems. Other intelligent MACdevices in the nPC2300 family are a highly-integrated 24-port derivativeof the nPC2315, a 12-port derivative with integrated PHYs, and anoversubscribed Nx10GE intelligent MAC.

Key features of nPC2315 are as follows. Ethernet Line Interfaces: 12Ethernet ports, 10/100/1000 Mbps tri-speed support, Serial Gigabit MediaIndependent Interface (SGMII) to PHYs.

System Interfaces: System Packet Level Interface Phase 4 Level 2(SPI-4.2), Supports up to 12 Gbps data rate (for media-speed operation),Also supports quarter-rate operation at 3 Gbps (for oversubscription),Packet and interleaved modes in both ingress and egress directions ORTwo GMII Ethernet interfaces (for up to 12:1 oversubscription) with loadbalancing support between the two interfaces.CPU Interfaces: 16-bit, 100-MHz Host CPU interface. Up to 200 Mbps ofpacket throughput.Integrated Memory: Total of 12 Mbits of internal memory, Up to 8 Mbitsof internal payload memory, Supports configurable partitions for use aspayload buffer memory, multi-field classification result blocks,user-defined counters, and/or policing contexts.Integrated Packet Classification Engine (PC-CAM): High-density TernaryContent Addressable Memory (TCAM), a CAM array with a 4-bit database IDand a 7-bit weight field per 64-bit entry for efficient tablemanagement, 256 Kbits in density, Support for 32-, 64-, 128-, and192-bit keys, Support for 16 databases via a 4-bit tag associated witheach 64-bit entry, Key size configurable on a per-database basis

Extended Feature Interfaces (EFIs)

-   -   Two external memory interfaces that can each be configured as        either a 16-bit QDR SRAM interface or a 32-bit RLDRAM interface:        -   QDR SRAM interface can be used as:        -   NPF LA-1 compliant interface to external TCAMs        -   External interface to QDR SRAM for user-defined counters            and/or policing contexts        -   Interface to user-designed coprocessing logic for features            differentiation    -   RLDRAM interface can be used as:        -   External Payload Memory Interfaces        -   With both external memory interfaces configured as external            payload at 330 MHz, the sustained throughput achieved is 10            Gbps, full duplex, for all packet sizes

Statistics

-   -   RMON Ethernet Statistics (defined in RFC 1757)    -   Support for 32- and 64-bit user-defined counters    -   Counters may be maintained in internal memory    -   Counters may be stored in external SRAM

Multi-Field Classification (MFC)

-   -   Multiple MFCs per ingress frame    -   Support for multiple MFC databases    -   An MFC database may reside in an internal TCAM or external TCAM    -   Key sizes defined on a per-database basis, with support for 32-,        64-, 128-, and 192-bit keys    -   Flexible, user-defined configuration of the fields that comprise        each key    -   Symbolic definition of selected fields, which may not always be        at a fixed offset within the frame (for example, VLAN IDs)    -   Byte-granular fields at configured offset relative to start of        MAC header, start of Layer-2 payload, start of IPv4 payload,        and/or start of IPv6 payload    -   Nested MFC key defined by preceding MFC result    -   Per-port configuration of multiple key selection for the initial        MFC that is performed on a frame, where:    -   First key is used for IPv4 frames    -   Second key is used for IPv6 frames    -   Third key is used for MPLS frames    -   Fourth key is used for all other frame types    -   Powerful set of actions that can be specified as a result of an        MFC match:    -   Increment the counter by 1    -   Increment the counter by the length of the frame in octets    -   Discard the frame    -   Assign a VLAN priority to the frame    -   Assign a VLAN ID to the frame    -   Assign a Differentiated Services Code Point (DSCP) value to the        frame    -   Police the frame    -   Explicitly select a queue for the frame    -   Select a modification profile to be performed on the frame, for        example:    -   Add VLAN Tags    -   Remove VLAN Tags    -   Set user data to be associated with the frame in the header that        may be optionally prepended before forwarding    -   Indicate whether a subsequent MFC is to be performed, and        specify the key to be used for the MFC

Port Security

-   -   Per-port configuration mode, where an ingress frame is accepted        only if its source MAC address matches one of a configured set        of source MAC addresses    -   Special case for Multi-field Classification (MFC)    -   Configured set of source MAC addresses may be stored in an        integrated CAM, or in an external TCAM    -   Key for source MAC address lookup in the port-security database        includes a 4-bit GE port number, along with the 48-bit MAC        address

Policing

-   -   Multiple policing operations per ingress frame    -   Byte-level granularity    -   Standard-based Token Bucket algorithms    -   Support for Single-Rate Three-Color Marker (defined in RFC 2697)    -   Support for Two-Rate Three-Color Marker (defined in RFC 2698)    -   Support for color-blind and color-aware modes    -   Table-driven mechanism to determine the pre-color for        color-aware mode; indexed by the MFC result    -   Table-driven mechanism to determine the action for        non-conforming frames, where actions include:    -   Discard the frame    -   Mark the frame    -   Initiate flow control    -   Support for incrementing a counter when a frame is discarded due        to non-conformance, where the counter to increment is specified        as part of the MFC result block that initiated the policing        operation

Queuing

-   -   96 queues for ingress transmission onto the system (uplink)        interface    -   Four queues for the CPU Host interface (two for ingress, two for        egress)    -   24 queues for egress transmission onto the Ethernet line        interface    -   Ingress queue selected by a table-driven mechanism that can be        overridden by the MFC result    -   Three ingress queue-selection tables for each Ethernet line        interface port, where:    -   First table is for IP frames and is indexed by the DSCP value    -   Second table is for MPLS frames and is indexed by the EXP value    -   Third table is for all other frame types and is indexed by the        VLAN priority value    -   Load-balancing across multiple Ethernet system interfaces using        one of the following algorithms configurable on a line-interface        basis:    -   Assignment of line interface to a particular system interface    -   Hashing based on {source IP address, destination IP address, IP        protocol, source port number, destination port number} 5-tuple    -   Hashing based {destination MAC address, source MAC address}        tuple

Admission Control

-   -   Dynamic Threshold Admission Control or Weighted Random Early        Detection (WRED) Admission Control, selectable on a per-queue        basis    -   Dynamic Thresholding    -   102 Dynamic Threshold Groups (96 ingress, two egress, and four        CPU)    -   Six Dynamic Threshold profiles (four ingress, one egress, and        one CPU)    -   Eight regions per group    -   Two threshold values per region: discard and queue limit    -   WRED Thresholding    -   96 WRED Groups (ingress queues)    -   Four WRED profiles    -   Eight regions per profile    -   Three threshold values per region: green, yellow, and red    -   Region is determined based on the threshold group buffer        occupancy and/or overall payload memory buffer occupancy

Scheduling

-   -   Sophisticated hierarchical scheduling: Output Queue level and        Port level    -   Schedulers at each level can be configured for Strict Priority        (SP) or Weighted Round Robin (WRR) scheduling    -   A Maximum Shaper can be configured for each scheduler to impose        an upper-bound on the rate at which traffic is scheduled    -   Shaped Egress traffic characteristics are maintained        (optional—available only if no multicast is activated)

Packet Modification

-   -   128 ingress frame modification profiles for        adding/removing/modifying frame content    -   16 egress frame modification profiles for        adding/removing/modifying frame content    -   Each modification profile supports 16 packet modification        commands (actions)    -   Ingress profile selectable by the Multi-Field Classification        (MFC) or Extended Feature Interface (EFI) result    -   Egress profile selectable by the egress classification header        generated by an upstream device or forwarding subsystem        somewhere else in the system

Flow Control

-   -   IEEE 802.3x flow control    -   Can be initiated as a result of policing non-conformance    -   Can be initiated as a result of admission control    -   SPI-4.2 flow control    -   Can be initiated as a result of admission control

IP Header Checksum

-   -   Supports IP Header Checksum recalculation and rewrite

VLAN Support

-   -   VLAN state awareness    -   4K VLAN ID classifications per port    -   Nested VLAN support

Egress Multicast

-   -   One multicast queue per port, up to one copy per port    -   Up to 1K multicast packets per port

The nPC2315 supports Multi-Field Classification (MFC) of ingress framesreceived from Ethernet line interfaces. Zero, one, or multiple MFCs maybe performed for each received frame. The number of MFCs that can beperformed per frame without impacting forwarding performance isdependent upon the key sizes used and the particular databases that arebeing accessed (for example, whether the databases are internal orexternal) as discussed below. The basic flow is straightforward:Per-port configuration parameters control whether an initial MFC isperformed, and if so, what key and database should be used. An MFCresult block is associated with each MFC database entry. The resultblock specifies actions that are to be performed when a lookup matchesthe entry. One of the supported actions indicates that a subsequent MFCis to be performed. The Set MFC Action specifies the key and databasethat are to be used for the subsequent MFC.

The nPC2315 supports definition of multiple different key formats. Keysare defined in a flexible manner using the parameters shown in FIG. 9,as described below.

Domain Number

A 4-bit domain number may be configured for each Ethernet lineinterface.

The domain number can be used to conserve MFC database space by enablinga single policy entry to be applied to a group of ports that areassigned to the same domain.

EtherType or DSAP/SSAP

-   -   The Ethernet v2 and IEEE 802.3 SNAP encapsulation formats        contain an EtherType field that is used to identify the type of        Layer-3 protocol data unit that is contained in the frame's        information field. The non-SNAP IEEE 802.3 LLC encapsulation        does not contain an EtherType field, but does contain DSAP and        SSAP fields that can be used to identify the type of protocol        data unit that is contained in the frame's information field.        The key field associated with the EtherType or DSAP/SSAP        parameter contains either an EtherType value or {DSAP,SSAP}        values from the frame based on the encapsulation type (where the        8-bit DSAP value is taken from byte-offset 14 in the frame and        the 8-bit SSAP value is taken from byte-offset 15 in the frame).    -   The IEEE 802.1Q standard defines an EtherType value of x8100 to        indicate the presence of a VLAN Tag. The initial EtherType is        followed by a 16-bit VLAN Tag, which is followed by a second        EtherType value that is used to identify the type of Layer-3        protocol data unit carried in the frame. Network equipment        vendors have expanded the VLAN Tag concept to support multiple        nested VLAN Tags. In doing so, some vendors have used        non-standard EtherType values (for example, x9100 or x88A8).        Consequently, the nPC2315 provides special support to flexibly        identify the presence of VLAN Tags. A frame is considered tagged        if its EtherType matches either of two port-based configurable        values: taggedVlanEtherType_(—)1 or taggedVlanEtherType_(—)2.        Additionally, a tagged frame is deemed to contain multiple VLAN        Tags if the 16-bit EtherType value immediately following the        outermost VLAN Tag matches either taggedVlanEtherType_(—)1 or        taggedVlanEtherType_(—)2. For frames containing a single VLAN        Tag, the EtherType key field contains the 16-bit value        immediately following the VLAN Tag in the frame. For frames        containing multiple VLAN Tags, the EtherType key field contains        the 16-bit value immediately following the second VLAN Tag in        the frame.

VLAN Tag

A VLAN Tag Attribute value is associated with each frame received by anEthernet line interface. A defaultVlanTag configuration parameter isassociated with each Ethernet line interface. For untagged frames, theVLAN Tag Attribute value associated with the frame is the contents ofthe defaultVlanTag parameter defined for the receiving port. For framesthat contain a VLAN Tag, the VLAN Tag Attribute value associated withthe frame is the contents of the outermost VLAN Tag in the frame. Ineither case, the VLAN Tag key field contains the VLAN Tag Attributevalue associated with the frame.

Nested VLAN Tag

When a frame contains multiple VLAN Tags, the Nested VLAN Tag key fieldcontains the second VLAN Tag in the frame. The Nested VLAN Tag key fieldis set to x0000 for frames that do not contain multiple VLAN Tags.

VLAN ID/Nested VLAN ID

The VLAN ID/Nested VLAN ID key field is a special case designed toenable efficient utilization of MFC database space (that is, where eachdatabase entry is 32 bits). The VLAN ID component of the key fieldcontains the least-significant 12 bits of the VLAN Tag value associatedwith the frame. When a frame contains multiple VLAN Tags, the NestedVLAN ID component of the key field contains the least-significant 12bits of the second VLAN Tag in the frame. The Nested VLAN ID componentof the key field is set to x000 for frames that do not contain multipleVLAN Tags.

VLAN STP State

The VLAN STP State field may be used to include the current SpanningTree Protocol (STP) state in the MFC key. The nPC2315 maintains a4K×2-bit array for each Ethernet line interface that can be programmedto indicate the STP state on a per-VLAN basis. When a frame is receivedby an Ethernet line interface, the VLAN ID component of the VLAN TagAttribute is used as an index into the VLAN STP State Array. Thecontents of the selected array entry are stored in the VLAN STP StateAttribute associated with the frame. The VLAN STP State key fieldcontains the VLAN STP State Attribute value associated with the frame.

MAC Offset

The MAC Offset parameter is used to specify a key field that contains an8-bit value taken from the frame contents at a configured byte-offsetrelative to the beginning of the MAC header (that is, the first byte ofthe Destination MAC Address is at offset 0). Multiple MAC Offsetparameters may be used in a single key definition. For example, theSource MAC Address could be included in the key using six MAC Offsetparameters, with offsets 6-11. The maximum byte-offset that can beconfigured for the MAC offset parameter is 127.

L2 Payload Offset

The L2 Payload Offset parameter is used to specify a key field thatcontains an 8-bit value taken from the frame contents at a configuredbyte-offset relative to the beginning of the Layer-2 Payload. As anexample, consider that for an IP frame, the first byte of the IP headeris at offset 0. Multiple L2 Payload Offset parameters may be used in asingle key definition. As another example, consider that for a MPLSframe, the outermost label-stack entry could be included in the keyusing four L2 Payload Offset parameters, with offsets 0-3. To enable theL2 Payload Offset parameter functionality, the nPC2315 includes logic toidentify the beginning of the Layer-2 payload. This logic operates asfollows:

a) Ethernet v2 encapsulation with no VLAN Tags, Layer-2 payload beginsat byte-offset 14 in the frame.b) Ethernet v2 encapsulation with one VLAN Tag, Layer-2 payload beginsat byte-offset 18 in the frame.c) Ethernet v2 encapsulation with multiple VLAN Tags, Layer-2 payloadbegins at byte-offset 22 in the frame.d) IEEE 802.3 SNAP encapsulation with no VLAN Tags, Layer-2 payloadbegins at byte-offset 22 in the frame.e) IEEE 802.3 SNAP encapsulation with one VLAN Tag, Layer-2 payloadbegins at byte-offset 26 in the frame.f) IEEE 802.3 SNAP encapsulation with multiple VLAN Tags, Layer-2payload begins at byte-offset 30 in the frame.g) IEEE 802.3 non-SNAP encapsulation, Layer-2 payload begins atbyte-offset 14 in the frame.

The maximum byte-offset that can be configured for the L2 Payload Offsetparameter is 63.

IP Payload Offset

The IP Payload Offset parameter is used to specify a key field thatcontains an 8-bit value taken from the frame contents at a configuredbyte-offset relative to the beginning of the IP Payload. As an example,consider that for an IPv4 frame carrying TCP, the first byte of the TCPheader is at offset 0.

Multiple IP Payload Offset parameters may be used in a single keydefinition. As a second example, consider that for an IPv4 TCP frame,the Destination Port could be included in the key using 2 IP PayloadOffset parameters, with offsets 2 and 3.

-   -   For IPv4, the nPC2315 calculates the start of the IP Payload        field based on the value of Header Length in the IP header.    -   For IPv6, the IP Payload field starts 40 bytes from the        beginning of the IPv6 header. The maximum byte-offset that can        be configured for the IP Payload Offset parameter is 31. The IP        Payload Offset parameter is supported for Ethernet v2 and 802.3        SNAP encapsulations. The IP Payload Offset parameter is not        supported for 802.3 non-SNAP encapsulations.

User Data Attribute Offset

The User Data Attribute Offset parameter is used to specify a key fieldthat contains an 8-bit value taken from the User Data Attributeassociated with the frame. The value is taken from a location at aconfigured byte-offset relative to the beginning of the User DataAttribute. For example, the first byte of the User Data Attribute is atoffset 0, the second byte is at offset 1, and so on. The contents of theUser Data Attribute associated with a frame may be set by specifying aSet User Data Action in an MFC result block as described below. Onepossible use of the User Data Attribute Offset parameter is to utilizeresults from a previous MFC operation as a component of the key forsubsequent MFC operations.

The MFC key format consists of eight fixed-function header bits followedby user-defined fields, as shown in FIG. 10. Note: Four different keysizes are supported: 32, 64, 128, or 192 bits. The user-defined fieldsof an MFC key are configured by specifying a sequence of the keydefinition parameters shown in FIG. 9. An MFC lookup operation isconfigured by specifying the parameters shown in FIG. 11.

The nPC2315 supports definition of 64 different sets of MFC LookupParameters. A particular set of MFC Lookup Parameters is identifiedusing an MFC ID with values in the range [0 . . . 63]. The KeyDefinition Parameter List merits additional explanation. The list iscomposed of a sequential array containing 26 entries. The list isvariable-sized, ranging from 0 to 26 entries, with the Key DefinitionParameter Count indicating the number of valid entries. All of the validentries must appear sequentially, beginning with the first array entry.Each entry in the list is composed of a 4-bit Parameter ID field and a7-bit Parameter Argument field, as shown in FIG. 12.

-   -   The Parameter ID field identifies one of the key definition        parameters defined in FIG. 9.    -   The Parameter Argument field is used to specify the byte-offset        associated the MAC Offset, L2Offset, IP Payload Offset, and User        Data Attribute Offset parameters.

Note that the total size of the key fields produced by the KeyDefinition Parameter List is limited by the size of the key defined forthe database that the lookup accesses; more specifically, the total sizeof the key fields produced by the Key Definition Parameter List islimited by the size of the User-Defined component of the key as definedin FIG. 10. FIG. 12 shows Format of Key Definition Parameter List Entry.The initial MFC lookup is controlled by the parameters shown in FIG. 13.Note: There are separate sets of parameters for controlling the initialMFC lookup at each Ethernet line interface. Also note that the followingthroughout this specification:

-   -   IPv4 frames are identified by an Ethernet v2 or IEEE 802.3 SNAP        encapsulation with an EtherType value of x0800.    -   IPv6 frames are identified by an Ethernet v2 or IEEE 802.3 SNAP        encapsulation with an EtherType value of x86DD.    -   MPLS frames are identified by an Ethernet v2 or IEEE 802.3 SNAP        encapsulation with an EtherType value of x8847.

MFC Actions

An MFC result block is associated with each MFC database entry. Theresult block specifies actions that are to be performed when a lookupmatches the entry. If there is no match on an MFC lookup, then theforwarding procedure continues to the queue selection phase. Similarly,if a frame is not discarded as the result of an MFC action, then theforwarding procedure continues to the queue selection phase uponcompletion of the last MFC for the frame. An MFC result block alwaysincludes a 32-bit action specification header, and may include anoptional set of extension fields. The format of the header is shown inFIG. 14. The format of an MFC result block is illustrated in FIGS. 15Aand 15B. Multiple actions can result from an MFC lookup. Actions areperformed in the order in which they are listed in FIG. 14. If theDiscard Frame Action is specified, no subsequent actions are applicable.All of the fields in the MFC result block, except for the header, areoptional. If an optional field is present, it must appear in the orderlisted in FIGS. 15A and 15B. The following are additional descriptionsof MFC result block fields:

Result Block Size

The size of the MFC result block, including the header, is specified inthe Result Block Size field within the header. The result block sizemust be a multiple of 64 bits, and four different sizes are supported(that is, 64, 128, 192, and 256 bits). The value specified in the ResultBlock Size field controls the number of memory reads performed by thenPC2315 to fetch the result block. There is no requirement that thespecified block size be completely utilized for MFC fields (that is, atrailing portion of the block can be unused). However, there is arequirement that all of the fields associated with the specified actionsmust fit within the specified block size. It is an error to specify acombination of actions for which the associated fields do not fit in thespecified block size.

Set Counter 1 Action, Set Counter 2 Action (Counter Pointer)

Zero, one, or two counter operations may be specified in an MFC resultblock. If the Set Counter 1 Action is specified in the header, then theCounter 1 Size field is present in the body of the result block.Similarly, if the Set Counter 2 Action is specified in the header, thenthe Counter 2 Size field is present in the body of the result block. Ifeither the Set Counter 1 Action or the Set Counter 2 Action is specifiedin the header, then the Counter Pointer field is present in the body ofthe result block. If both the Set Counter 1 Action and the Set Counter 2Action are specified, then the counters must be stored in contiguousmemory locations (with Counter 1 first, followed by Counter 2).

Set Discard Counter Action (Number of Discard Counters, Discard

Counter Size, Discard Counter Pointer) The Set Discard Counter Actionmay be used to maintain statistics regarding frames that are discardedas a result of the Discard Frame Action, the Police Action, or admissioncontrol features. If the Set Discard Counter Action is specified in theheader, then the Number of Discard Counters, Discard Counter Size, andDiscard Counter Pointer fields are present in the body of the resultblock. The Number of Discard Counters field specifies the number ofdiscard counters contained in the memory block pointed to by the DiscardCounter Pointer field. The following formats are supported:

-   -   A format with a single discard counter.    -   A format with three discard counters, where the first counter in        the memory block is for green-colored frames, the second counter        in the memory block is for yellow-colored frames, and the third        counter in the memory block is for red-colored frames. The        specified Discard Counter Size applies to all the counters in        the memory block. Note: The Color Attribute of a frame received        by an Ethernet line interface is initialized to green upon        reception, and may be subsequently altered as the result of a        policing operation.

Set Interface Action (Interface Number)

If the Set Interface Action is specified in the result block header,then the Interface Number field is present in the body of the resultblock. The Interface Number field in the result block explicitlyidentifies an interface that the frame is to be forwarded out. Validinterfaces include the following:

-   -   System interface #1    -   System interface #2    -   CPU interface

Set User Data Action (User Data Byte 0-6 Mode, User Data Byte 0-6Source) If the Set User Data Action is specified in the result blockheader, then the User Data Byte 0-6 Mode and the User Data Byte 0-6Source fields are present in the body of the result block. The Set UserData Action sets the value of the User Data Attribute associated withthe frame. The value of the User Data Attribute is initialized to 0 whena frame is received from an Ethernet line interface. A subset of theattributes associated with a frame, including the User Data Attribute,are accessible as parameters to the frame modification profile. Themodification profile may interpret the User Data Attribute directly asuser data or as an address of a memory block containing user data. TheUser Data Attribute size is seven bytes, where Byte 0 contains theleast-significant eight bits (that is, bits 0-7), and Byte 6 containsthe most-significant eight bits (that is, bits 48-55). The body of theMFC result block contains a User Data Byte Mode field for each byte ofthe User Data Attribute (that is, the User Data Byte 0 Mode fieldcontrols the operation performed on Byte 0 of the User Data Attribute).The following types of operations may be specified by a User Data ByteMode field:

-   -   No operation (that is, do not modify the associated byte of the        User Data Attribute).    -   Write Immediate User Data to the associated byte field within        the User Data Attribute.    -   Write a byte of the current MFC key to the associated field        within the User Data Attribute.

The body of the MFC result block also contains a User Data Byte Sourcefield that is associated with each User Data Byte Mode field. Thecontents of a User Data Byte Source field may be used as follows:

-   -   If the operation to be performed utilizes immediate data, then        the User Data Byte Source field contains the immediate data that        is written to the associated byte field within the User Data        Attribute.    -   When the operation to be performed utilizes data extracted from        the current MFC key, the User Data Byte Source field contains a        byte-offset relative to the beginning of the current MFC key.        The byte-offset identifies the location within the current MFC        key at which user data is to be extracted. The user data        extracted from the MFC is then written to the associated byte        field of the User Data Attribute. As a final comment on this        topic, note that the contents of the User Data Attribute can be        used as a component of MFC keys. Thus, the Set User Data Actions        also provide a mechanism for conveying results from one MFC into        a subsequent MFC operation.

Set VLAN Priority Action, Set VLAN ID Action (VLAN Priority, VLAD ID)

As discussed previously, a VLAN Tag Attribute is associated with eachframe received by an Ethernet line interface. The VLAN Tag Attributecontains two sub-attributes, the VLAN Priority Attribute and the VLAN IDAttribute, which can be independently modified by MFC actions.

-   -   If the Set VLAN Priority Action is specified in the result block        header, then the VLAN Priority field is present in the body of        the result block. The content of the VLAN Priority field in the        result block is used as the value of the VLAN Priority Attribute        associated with the frame.    -   If the Set VLAN ID Action is specified in the result block        header, then the VLAN ID field is present in the body of the        result block. The content of the VLAN ID field in the result        block is used as the value of the VLAN ID Attribute associated        with the frame.

Set DSCP Action (DSCP)

A DSCP Attribute is also associated with IP frames. The DSCP Attributeis initialized to the value of the DSCP field in the frame's IP header(that is, the most-significant six bits of the TOS field in the IPheader). The DSCP Attribute can be subsequently modified as the resultof MFC actions. If the Set DSCP Action is specified in the result blockheader, then the DSCP field is present in the body of the result block.The content of the DSCP field in the result block is used as the valueof the DSCP Attribute associated with the frame.

Police Action (Policing Algorithm, Policing Mapping Tables SelectionMode, Pre-Color Mapping Mode, Policing Result Mapping Mode, and PolicingContext Pointer)

If the Police Action is specified in the result block header, then thePolicing Algorithm, Policing Mapping Tables Selection Mode, Pre-ColorMapping Mode, Policing Result Mapping Mode, and Policing Context Pointerfields are present in the body of the result block.

-   -   The Policing Algorithm field specifies the policing algorithm        that is to be used.    -   The Policing Mapping Tables Selection Mode is used to select the        set of mapping tables to be used for the policing operation.    -   The Pre-Color Mapping Mode field is used when determining the        color of frame prior to executing a color-aware policing        algorithm.    -   The Policing Result Mapping Mode field is used when determining        the actions to be performed as a result of the policing        operation.    -   The Policing Context Pointer field in the result block contains        the address of a data structure representing the context for the        policing operation that is to be performed.

Set Queue Action (Queue Number)

If the Set Queue Action is specified in the result block header, thenthe Queue Number field is present in the body of the result block. TheQueue Number field in the result block explicitly identifies a queue towhich the frame is to be assigned.

Set Modification Profile Action (Profile Selection Algorithm,Modification Profile ID)

If the Set Modification Profile Action is specified in the result blockheader, then the Profile Selection Algorithm field and the ModificationProfile ID field are present in the body of the result block.

-   -   The Set Modification Profile Action sets the value of the        Modification Profile ID Attribute associated with the frame.    -   The Modification Profile ID Attribute selects a particular set        of user-defined commands that are to be executed before the        frame is forwarded. The Modification Profile ID is set to a        default value of 0 when a frame is initially received from an        Ethernet line interface. The Modification Profile ID field in        the result block is used as a parameter to the Profile Selection        Algorithm.

The following profile selection algorithms are supported:

-   -   Modification Profile ID Attribute=Modification Profile ID Field    -   Modification Profile ID Attribute=Modification Profile ID        Attribute+Modification Profile ID Field This algorithm enables a        subsequent MFC to modify the profile selection made by a        previous MFC. For example, one MFC could select a block of        profiles, and a subsequent MFC could then use this algorithm to        select a particular profile from the previously selected block.    -   Modification Profile ID Attribute=Modification Profile ID        Field+Encapsulation Attribute

This algorithm enables conservation of MFC entries, since one MFC can beused for multiple encapsulation types, and this algorithm can then beused to select the proper modification profile for the given frameencapsulation type. More specifically, the algorithm supports selectionof different modification profiles for the Ethernet v2, 802.3 SNAP, and802.3 non-SNAP frame encapsulations.

-   -   Modification Profile ID Attribute=Modification Profile ID        Field+((VLAN Tag Count Attribute<<2)+Encapsulation Attribute))

This algorithm enables conservation of MFC entries, since one MFC can beused for multiple frame formats, and this algorithm can then be used toselect the proper modification profile for the given frame format. Morespecifically, the algorithm supports selection of different modificationprofiles for the following frame formats:

-   -   Ethernet v2 encapsulation with no VLAN Tags    -   Ethernet v2 encapsulation with one VLAN Tag    -   Ethernet v2 encapsulation with two VLAN Tags    -   802.3 SNAP encapsulation with no VLAN Tags    -   802.3 SNAP encapsulation with one VLAN Tag    -   802.3 SNAP encapsulation with two VLAN Tags    -   802.3 non-SNAP encapsulations)

The values of the Encapsulation Attribute and the VLAN Tag CountAttribute are shown in FIG. 16.

Note: The Modification Profile Attribute is not applicable for framesthat are forwarded via the Host CPU interface (since the packettransformation feature is not available for frames forwarded via theHost CPU interface).

Set MFC Action (MFC ID)

-   -   If the Set MFC Action is specified in the result block header,        then the MFC ID field is present in the body of the result        block. The MFC ID field in the result block identifies a set of        lookup parameters for the next MFC that is to be performed on        the frame.    -   If the Set MFC Action is not specified in the result block        header, then the current MFC is the final MFC performed on the        frame.    -   If multiple MFCs are performed for a frame, and a given action        is specified multiple times, then the most recently specified        action takes precedence. More specifically, this precedence rule        applies to the following actions:    -   Set Discard Counter Action    -   Set VLAN Priority Action    -   Set VLAN ID Action    -   Set DSCP Action    -   Set Queue Action    -   Set Interface Action    -   Set User Data Action    -   Set Modification Profile Action

Note: A caveat to the above precedence rule exists for the Set User DataAction and the Set Modification Profile Action, since algorithms aredefined for these actions that enable the most recent action to eithercompletely override or incrementally modify previous actions.

Frame Attributes

The discussion of the MFC Actions above has identified some attributevalues that may be associated with a frame. Attribute values are used atvarious stages of processing within the nPC2315. For example:

-   -   The Color Attribute and DSCP Attribute may be used during        policing operations.    -   The VLAN Priority Attribute and DSCP Attribute may be used as        the basis for queue selection.    -   The Color Attribute may be used during admission control.

Additionally, a subset of the attributes values are made available asparameters to the frame modification profile. The frame modificationprofile may write attribute values to the associated fields within theframe, or include attribute values in a header that is optionallyprepended to frames prior to transmission. FIG. 16 contains a list ofthe frame attribute values. A frame modification profile does not haveaccess to all of the attribute values associated with a frame. A framemodification profile may access up to 80 bits of frame attribute values.The subset of frame attribute values that are accessible is configurableon a frame modification profile basis. The Frame Length Attribute andModification Profile ID Attribute are always included in the subset ofattribute values accessible by a frame modification profile, whichleaves 56 bits of user-selectable frame attribute values. Theuser-selectable attribute values are configured via a Frame AttributeSelection Register. One Frame Attribute Selection Register is providedfor each frame modification profile. The format of a Frame AttributeSelection Register is shown in FIG. 17.

The attributes accessible to a frame modification profile are stored inthe order that they are listed in FIG. 16. Thus, the 80-bit attributearray always begins with the 16-bit Frame Length Attribute followed bythe 8-bit Modification Profile ID Attribute. The attributes explicitlyselected via the Frame Attribute Selection Register are stored after theModification Profile ID Attribute. The User Data Attribute, startingwith the most-significant bits, is then stored after all the explicitlyselected attributes.

As an example, consider a frame modification profile for which the VLANTag Attribute, the VLAN STP State Attribute, and the DSCP/EXP Attributeare explicitly selected. In this case, the 80-bit accessible attributearray contains the following:

-   -   16-bit Frame Length Attribute    -   8-bit Modification Profile ID Attribute    -   16-bit VLAN Tag Attribute    -   2-bit VLAN STP State Attribute    -   6-bit DSCP/EXP Attribute    -   Most-significant 32 bits of the User Data Attribute

1. A method of processing data from a network, the method comprising: identifying, from a value at a fixed location in a frame, a type of encapsulation of data in the frame; extracting a plurality of attributes of the frame from a corresponding plurality of locations in the frame based on the type of encapsulation; wherein at least one attribute being extracted is at different locations in frames of different types of encapsulation; generating a key by use of said attributes and independent of the type of encapsulation.
 2. The method of claim 1 further comprising: using at least said key, to identify a plurality of instructions.
 3. The method of claim 2 further comprising: executing at least one instruction in said plurality of instructions.
 4. The method of claim 1 further comprising: concatenating the key, with an identifier of a port on which the frame is received, to generate a modified key; and using at least said modified key, to identify a plurality of instructions.
 5. The method of claim 4 further comprising: concatenating the modified key, with an identifier of a database associated with the port, to generate an extended key; wherein at least said extended key is used to identify the plurality of instructions.
 6. The method of claim 1 wherein: the key is generated by concatenating said attributes.
 7. The method of claim 1 wherein the different types of encapsulation comprise two or more of: encapsulation with no VLAN tags; encapsulation with one VLAN tag; and encapsulation with two VLAN tags.
 8. The method of claim 7 wherein at least one of said types of encapsulations conforms to Ethernet.
 9. The method of claim 7 wherein at least another of said types of encapsulations conforms to 802.3.
 10. The method of claim 1 further comprising: generating an additional key by use of an additional group of attributes; and reading memory using at least the additional key.
 11. The method of claim 1 further comprising: using said key directly, without any logic processing, to perform a memory look-up.
 12. An integrated circuit for processing data from a network, the integrated circuit comprising: first hardware means for identifying, from a value at a fixed location in a frame, a type of encapsulation of data in the frame; and second hardware means, coupled to the first hardware means, for extracting a plurality of attributes of the frame from a corresponding plurality of locations in the frame based on the type of encapsulation; wherein at least one attribute being extracted is at different locations in frames of different types of encapsulation; and third hardware means, coupled to the second hardware means, for generating a key from attributes independent of encapsulation type.
 13. The integrated circuit of claim 12 further comprising: a memory, coupled to the third hardware means, to receive therefrom the key to be used in looking up the memory; and a processor coupled to the memory to receive therefrom instructions to be executed by the processor as identified by the key.
 14. An integrated circuit (IC) comprising: an input port; an encapsulation dependent hardware coupled to the input port to receive a frame; a plurality of first storage elements, coupled to the encapsulation dependent hardware, the first storage elements holding a plurality of attributes of the frame; a plurality of second storage elements holding identifiers of a subset of first storage elements; an encapsulation independent hardware coupled to the plurality of second storage elements to receive therefrom said identifiers, the encapsulation independent hardware being further coupled to the plurality of first storage elements to receive therefrom values of attributes in the subset; and a register coupled to receive an output of the encapsulation independent hardware.
 15. The integrated circuit of claim 14 further comprising: a memory, coupled to the register, to receive therefrom a value to be used in looking up the memory; and a processor coupled to the memory to receive therefrom instructions to be executed by the processor as identified by the value in the register. 